Looking to resolve a few fundamental problems:

1. When making a change from HEAD the API call promises return to components that have been unmounted, which is destined to fail
2. It is incredibly difficult to direct the UI correctly when a user makes a change to HEAD that creates a new change set.
3. When router.push/router.replace is called, the vue router believes the currentRoute is the "original" (what is still in the URL bar), so subsequent router actions are almost always wrong which put the user right back to where they came from.
4. We were dropping WsEvents on the floor when a user makes a change to HEAD, the WsEvent topics were correctly using the new changeSetId, however no stores were subscribed to receive them yet
5. Now that we have mgmt functions which can create/update views & components, they may fire events that would normally navigate a user through the diagram, potentially creating chaos

With these changes:

• Don't reference router.currentRoute, we store the "intended" URL in routerStore.currentRoute
• Store actions that result in setSelected... or select... should not run in onActivated
• Store onActivated generally shouldn't load data (one exception that works just fine is the component_attribute.store)
• These should get moved to onBeforeMount of the appropriate component
• Stores should be guarded from calling router.push/router.replace when their change set is not the selected change set
• Do not await API responses in components and call setSelected... or select...
• WsEvents from the system now return the "actor" (userPk) in their metadata
• WsEvent subscriptions now should call setSelected... or select... when the actor is the current user
• Add WsEvents that belong to a newly created change set to a buffer that gets drained once new subscriptions start
• Keep track of which API endpoints create which WsEvents, so we can choose to ignore setSelected... or select... based on which API (like mgmt function) caused the event.

We shouldn't have to think about handling the "happy case" when in a change set, vs the "hard" case of "on head". Now, we don't have to await and check for HTTP 200, we just check the user in the WsEvent (and we don't lose any WsEvents).